<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
	<head>
		<meta http-equiv="content-type" content="text/html; charset=utf-8">
		<title>Simulator implementation</title>
	</head>
	<body>
		<h1>Simulator implementation</h1>
		<p>
		There are a couple of design decisions for the simulator (<a href="http://www.es.ele.tue.nl/poosl/Tools/rotalumis/">http://www.es.ele.tue.nl/poosl/Tools/rotalumis/</a>) that developers of POOSL models should be aware of.
		</p>

		<h2>Evaluation of debugging printString methods</h2>
		<p>
		When debugging a POOSL model, string representations of data values are displayed in the Variables view and the Sequence Diagram view. 
		Such string representations are computed using the printString method of the value's data class.
		</p>
		<p>
		The execution of such a printString method could update some variables or could lead to an error.
		The simulator executes these debugging printString methods in a safe environment (based on an internal deep copy of the data), such that their execution cannot impact the further model execution.
		</p>
		<p>
		This safe environment is not obtained using the deepCopy method, but it is directly based on a copy of the internal state of the classes
		In this way we avoid issues with the <a href="ClassTypes.html">non-permanent native classes</a>, for which the execution of a deepCopy method would generate an error.
		In the safe environment, the execution of state-changing methods from the <a href="ClassTypes.html">non-permanent native classes</a> will immediately generate an error.
		</p>

		<h2>Evaluation of guards</h2>
		<p>
		When running or debugging a POOSL model the enabled transitions are determined continuously.
		To this end, the simulator evaluates conditions inside guarded statements and receive statements (and hence also the expressions inside send statements).
		During interactive debugging, the set of enabled transitions is also needed for computing the colors inside the Execution Tree view.
		</p>
		<p>
		The evaluation of such a guard may update some variables, or may lead to an error.
		Hence their evaluation may impact the further model execution.
		In particular any POOSL model must be able to deal with multiple additional evaluations of such guards.
		</p>

		<h2>Socket data class</h2>
		<p>
		The socket data class is implemented as an ipv4 socket. The following two aspects need to be taken into account:
		<ul>
		<li><b>Write priority</b>: Sockets can be used for both reading and writing, but priority is given to writing. While a model performs many write operations on a socket, the socket may (almost) stop receiving data.
		<li><b>Port reuse</b>: After closing a socket, it may take some time before the operating system releases the port, which may cause problems when restarting a POOSL model.
		When creating a socket on a certain port number, the simulator requests the operating system to reuse the port (if it still in use).
		As a consequence, there is no warning when two sockets try to use the same port at the same time.
		</ul>
		</p>
		
		<h2>RandomGenerator data class</h2>
		<p>The RandomGenerator data class is used to obtain random numbers for simulating probabilistic behavior. A random number generator emulates drawing samples from the sample space of a random variable in accordance with its distribution. This is accomplished by producing a repetitive sequence of (pseudo) random numbers as described by a suitable algorithm. An essential issue for obtaining credible performance results is the actual randomness of the generated random numbers. This randomness depends, amongst others, on the number of random numbers generated before reproducing the sequence and the statistical independency of the generated random numbers.</p>
		<p>POOSL allows the use of multiple instances of data class RandomGenerator. The challenge is to ensure the generation of nearly independent parallel sequences of random numbers for the different instances of RandomGenerator. To this end, the simulator uses a separate random number generator for each instance of data class RandomGenerator. Ensuring near independence of the parallel sequences with this approach requires to initialise the random number generators with different initial values (seeds) such that the parallel sequences of random numbers are non-overlapping (Notice that each random number generator uses the same algorithm for generating random numbers). Choosing these seeds should not be done without properly considering whether the parallel sequences are indeed non-overlapping. Simply using another random number generator for producing the seeds is generally insufficient for obtaining credible performance results.</p>
		<p>The simulator uses a separate Mersenne Twister for each instance of data class RandomGenerator. The Mersenne Twister has a periodicity of 2 &#94; 19937 - 1. The seeds are initialized automatically by means of another random number generator.</p>
				
		<h2>Resolving Non-Determinism</h2>
		<p>Next to generating random numbers for instances of data class RandomGenerator, the simulator requires a random number generator for probabilistically <a href="../simulating_models/launch_configuration.html#setting_seed">resolving non-determinism</a> in POOSL models. The simulator uses a separate Mersenne Twister with a fixed seed for resolving non-determinism. Notice that a fixed seed allows exact reproduction of a simulation (in case method randomiseSeed is not used in the model). For any simulation, it is assumed that the number of random numbers needed for resolving non-determinism is much larger than the number of random numbers required for instances of RandomGenerator. Therefore, the random numbers generated for the different purposes are considered to be nearly independent, which ensures obtaining credible performance results.</p> 
	</body>
</html>